PCI DSSコンプライアンスチェックを利用してセキュリティを強化するためにSecurity Hubで適切にチューニングしてみた

こんにちは、臼田です。

皆さん、コンプライアンスチェックしてますか？(挨拶

Security Hubではコンプライアンスチェックの機能があり、現在は下記2種類の基準が利用できます。

• CIS AWS Foundations Benchmark v1.2.0
• PCI DSS v3.2.1

CISについては先日下記記事で扱ったので、今回はPCI DSSの基準をチューニングしてみました。

うわっ…私のセキュリティスコア低すぎ…？Security HubのCISベンチマークの俺流チューニングで100%準拠を目指す

前置き

Security Hubやコンプライアンスチェックについての概要は上記ブログを参考にしてください。

PCI DSSについて軽く触れておきます。

PCI DSSはクレジットカード会員データを安全に取り扱う事を目的として策定された、クレジットカード業界のセキュリティ基準です。

詳細は下記などをご確認ください。

本来は上述の通りクレジットカード会員データを扱う企業が対応するものですが、ある程度有名なセキュリティ基準なので、取得する必要がない企業でもこれを基準にしたいという要望がよくあります。

そんな場合にも利用できると思うので、この想定で見ていこうと思います。

CISベンチマークの項目でもそうでしたが、PCI DSSのコンプライアンスチェックも一般的に利用しようと思ったら必ずしもすべてのチェック項目を満たす必要はないので、環境に合わせてチューニングすべきです。

チェック項目一覧

というわけでチューニングのためにチェック項目の一覧と軽い解説を載せます。現状では下記32種類の項目があります。

• [PCI.S3.1] S3 バケットはパブリック書き込みアクセスを禁止する必要があります
• [PCI.S3.2] S3 バケットではパブリック読み取りアクセスを禁止する必要があります
  • S3は特別な要件がない限りパブリックからアクセスできないようにすべきです。
• [PCI.S3.3] S3 バケットでクロスリージョンレプリケーションを有効にする必要があります
  • クロスリージョンレプリケーションを利用すると別リージョンへのデータの複製が可能です。
• [PCI.S3.4] S3 バケットでは、サーバー側の暗号化を有効にする必要があります
  • サーバーサイド暗号化により物理的なデータの取得を困難にします。
  • 主にセンシティブデータを扱う場合か、コンプライアンス要件対応のために利用します。
• [PCI.RDS.1] RDS スナップショットではパブリックアクセスを禁止する必要があります
• [PCI.RDS.2] RDS DB インスタンスではパブリックアクセスを禁止する必要があります
  • RDSインスタンスとスナップショットはパブリックからアクセスできないようにすべきです。
• [PCI.Lambda.1] Lambda 関数は、パブリックアクセスを禁止する必要があります
  • Lambda関数はパブリックからアクセスできないようにすべきです。
• [PCI.Lambda.2] ラムダ関数は VPC にある必要があります
  • PCI DSSとしてはPAN(カード会員番号)を扱うシステムが対象となり、その経路を適切に管理する必要があるため、PANを扱うLambda関数はVPC Lambdaとして利用する必要があります。
  • 一般的なLambda関数利用であればVPC Lambdaがデメリットになることも多いです。
• [PCI.Redshift.1] Amazon Redshift クラスターはパブリックアクセスを禁止する必要があります
  • Redshiftはパブリックからアクセスできないようにすべきです。
• [PCI.ES.1] Amazon Elasticsearch Service ドメインは VPC 内に存在する必要があります
  • Amazon ESはパブリックアクセスとVPCアクセスの2つの作成方法があります。
  • パブリックアクセスの場合データがパブリックネットワークを通ることになります。
  • 基本VPCアクセスで作成します。
• [PCI.ES.2] Amazon Elasticsearch Service ドメインは保存時の暗号化を有効にする必要があります
  • 暗号化により物理的なデータの取得を困難にします。
  • 主にセンシティブデータを扱う場合か、コンプライアンス要件対応のために利用します。
• [PCI.EC2.1] Amazon EBS スナップショットをパブリックに復元することはできません
  • EBSスナップショットはパブリックで利用できないようにすべきです。
• [PCI.EC2.2] VPC のデフォルトのセキュリティグループでは、インバウンドトラフィックとアウトバウンドトラフィックが禁止されます
  • デフォルトのセキュリティグループはEC2等の設定を省略した際に自動的に割り当てられることがあるため、必要以上にアクセスできないようにすべきです。
• [PCI.EC2.3] 未使用の EC2 セキュリティグループを削除する必要があります
  • 未使用のセキュリティグループは誤って使用しないように削除しておくことが好ましいです。
• [PCI.EC2.4] 未使用の EC2 EIP を削除する必要があります
  • 未使用のEIPは誤って使用しないように削除しておくことが好ましいです。
  • 費用の観点からも削除が好ましいです。
• [PCI.IAM.1] IAM ルートユーザーアクセスキーが存在してはいけません
  • ルートユーザーは強力なためアクセスキーを発行すべきではありません。
  • また通常ユーザー自体利用すべきではありません。
• [PCI.IAM.2] IAM ユーザーには IAM ポリシーをアタッチしないでください
  • IAMユーザーに直接ポリシーをアタッチすると管理が煩雑になるため、グループまたはロールにアタッチすべきです。
• [PCI.IAM.3] IAM ポリシーでは、完全な「*」管理権限を許可しないでください。
  • 最小権限を意識すべきです。
• [PCI.IAM.4] ルートユーザーに対してハードウェア MFA を有効にする必要があります
  • ルートアカウントは強力なためハードウェアMFAを利用するとより強固に守れます。
• [PCI.IAM.5] ルートユーザーに対して仮想 MFA を有効にする必要があります
  • ルートアカウントは強力なためMFAが必須です。
• [PCI.IAM.6] すべての IAM ユーザーに対して MFA を有効にする必要があります
  • AWSのコンソールはインターネットからアクセスできるため認証にはMFAが必須です。
• [PCI.AutoScaling.1] ロードバランサーに関連付けられた Auto Scaling グループは、ヘルスチェックを使用します
  • Auto ScalingのヘルスチェックにはEC2とELBのものが利用できますが、サービスの正常性を測るにはELBのヘルスチェックが適切です。
• [PCI.CloudTrail.1] CloudTrail ログは、AWS KMS CMK を使用して保存時に暗号化する必要があります。
  • CMKによる暗号化で、鍵へのアクセス権限がないユーザが閲覧することができなくなります。
• [PCI.CloudTrail.2] CloudTrail を有効にする必要があります
  • CloudTrailはAWS上でのAPI履歴を管理する必須機能。確実に全有効化すべきです。
• [PCI.CloudTrail.3] CloudTrail ログファイルの検証を有効にする必要があります
  • ログが改ざんされないように検証を有効にするといいです。
• [PCI.CloudTrail.4] CloudTrail 証跡は CloudWatch ログと統合する必要があります
  • アラームと合わせるために出力設定を行うといいです。
• [PCI.KMS.1] カスタマーマスターキー (CMK) ローテーションを有効にする必要があります
  • CMKはローテーション機能を活用することにより簡単にキーのローテーションが可能です。
• [PCI.SSM.1] Systems Manager によって管理される Amazon EC2 インスタンスは、パッチのインストール後に、パッチコンプライアンスのステータスが COMPLIANT である必要があります。
  • EC2の脆弱性管理を適切に行うためにパッチコンプライアンスはCOMPLIANT状態を保つべきです。
• [PCI.CW.1] 「root」ユーザーの使用には、ログメトリクスフィルターとアラームが存在する必要があります。
  • アラームを設定することにより影響度の高い操作を検知できます。
• [PCI.CodeBuild.1] CodeBuild GitHub または Bitbucket のソースリポジトリの URL は、OAuth を使用する必要があります
• [PCI.CodeBuild.2] CodeBuild プロジェクト環境変数にクリアテキストの認証情報を含めることはできません
  • クレデンシャルを適切に管理する必要があります。
• [PCI.Config.1] AWS Config を有効にする必要があります
  • AWS Configは変更管理を行う必須機能です。確実に全有効化すべきです。

無効化する項目

おまたせしました。ここからが本題です。

PCI DSSのチェック項目はところどころ具体的な項目がありますが、基準がクレジットカード会員情報なので一般的にはそこまでしなくてもいいなーという項目がぼちぼちあります。

というわけで下記項目を無効化するといいんじゃないかなーと思っています。

• [PCI.Lambda.2] ラムダ関数は VPC にある必要があります
  • Lambda周辺のアーキテクチャ含めてVPCに縛られないことによるメリットが多いです。
  • VPC内のセンシティブ情報を扱うRDSにアクセスするようなLambdaについてはVPCに置く必要がありますが、基本はVPC外なので無効化で問題ないと思います。
• [PCI.S3.3] S3 バケットでクロスリージョンレプリケーションを有効にする必要があります
  • S3は99.999999999%の耐久性を持っています。
  • 殆どのデータはクロスリージョンレプリケーションをする必要はないです。
• [PCI.S3.4] S3 バケットでは、サーバー側の暗号化を有効にする必要があります
  • サーバサイド暗号化を利用することにより意識せず保存されるデータが暗号化されます。
  • 物理的なアクセスに対する耐性ができます。
  • ただ、一般的には全てのデータをそこまでする必要はないと思います。
• [PCI.ES.2] Amazon Elasticsearch Service ドメインは保存時の暗号化を有効にする必要があります
  • センシティブデータを扱わない場合には必須ではないと思います。
• [PCI.CloudTrail.1] CloudTrail ログは、AWS KMS CMK を使用して保存時に暗号化する必要があります。
  • 適切なアクセス制御ができていれば、そこまでしなくてもいいと思います。
  • CMKを利用することにより、より厳重に管理することは可能です。
  • 暗号化要件が特にない場合には無効化してもいいでしょう。
• [PCI.KMS.1] カスタマーマスターキー (CMK) ローテーションを有効にする必要があります
  • 無理にCMKを利用する必要がないので、こちらも必要ないです。
  • CMKを利用する場合には利用しましょう。
• [PCI.IAM.4] ルートユーザーに対してハードウェア MFA を有効にする必要があります
  • ハードウェアMFAの管理は簡単ではないため必須でなくてもいいと思います。

私個人の独断と偏見で書いているのでご留意ください。ただ、一般的な環境ではこれらの内容が当てはまると思います。

逆にここに上がっていない項目に違反していたら適切に対応しましょう。

無効化する方法

CISの方と同じなので割愛します。

簡単にできます。

まとめ

Security HubのPCI DSSチェック項目を私なりにチューニングしてみました。

ある程度項目の意味も解説していますので、環境ごとさらにチューニングしたい場合も参考になると思います。

ぜひご活用ください。